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[57] ABSTRACT 

A method of checking the type of an object located on a 
remote computer in a distributed object environment com- 
puting system is disclosed. Initially, a type checking method 
to determine whether a remotely located object is of a 
specified type is invoked. In the invocation, a target interface 
identifier is included as an argument. A determination is then 
made as to whether the target interface identifier is equal to 
or a base for an apparent Interface identifier held by a proxy 
object located on the first computer. If the target interface 
identifier is determined to be equal to or a base for the 
apparent interface identifier, an afiSrmative indication to that 
effect is returned to the client process. If not. then the target 
interface identifier is then compared to a real interface 
identifier. In many embodiments, a call to the server host 
will have to be made in order to determine tiie real interface 
identifier. In some embodiments, a local cache memory can 
also be provided to store the results of such inquiries. The 
target interface identifier is then compared to the real inter- 
face identifier and a determination is made as to whether the 
target interface identifier is equal to or a base for the real 
interface identifier. The result is then returned to the client 
process. A method of checking the type of an object and 
additionally returning an output proxy object is also dis- 
closed. The ou^ut proxy object may be the (Kiginal input 
proxy object that has been widened to the class associated 
with the target interface identifier, or may be a newly created 
proxy object ttiat is of the same kind as the input proxy and 
of die same type as tiie target interface identifier. 

34 Claims, 11 Drawing SAieets 
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METHOD AND AWARATUS FOR 
DETERMINING TBE TYPE OF AN OBJECT 
IN A DISTRIBUTED OBJECT SYSTEM 

BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

The present invention relates generally to the fields of 
distributed computing systems, client-server computing and 
object-oriented programming. More specifically, the present 
invention relates to methods and apparatus for determining 
the type of an object in a distributed object system. 

2. The Relevant Art 

Object-oriented programming methodologies have 
received increasing attention over the past several years in 
response to the increasing tendency for software devel(^)ed 
using traditional programming methods to be delivered late 
and over budget. This stems from the fact that traditional 
programming techniques that emphasize procedural models 
and "'linear^ code tend to be di£5cult to design and maintain 
in many circumstances. Generally, large programs created 
using traditional methods are **brittle**. That is, even small 
changes can effect numerous elements of the programming 
code. Thus, minor changes made to the software in response 
to user demands can require major redesign and rewriting of 
the entire prograntL Also, the ability to handle data is 
breaking down because the volume of infomiation Is grow- 
ing at a faster rate than our ability to process it Computer 
hardware performance has increased dramatically over the 
past decade, yet software performance has not Traditional 
software approaches to designing, developing and maintain- 
ing information processing systems continue to limit our 
ability to manage data. 

Object-oriented programming strategies tend to avoid 
these problems because object methodologies focus on 
manipulating data rather than procedures ; thus providing the 
programmer with a more intuitive approach to modeling real 
world problems. In addition, objects encapsulate related data 
and procedures so as to hide that information from the 
remainder of dte program by allowing access to the data and 
procedures only through the object*s interface. Hence, 
dianges to the data and or procedures of the object are 
relatively isolated from the remainder of the program. This 
provides code ttiat is more easily maintained as conqiared to 
code written using traditional methods, as changes to an 
object's code do not affect the code in the other objects. In 
addition, the inherent modular nature of objects allows 
individual objects to be reused in different programs. Thus, 
programmers can develop libraries of **tried and true** 
objects that can be used over and over again in different 
applications. This modularity increases software reliability 
while decreasing development time, as reliable program- 
ming code may be used repeatedly. For further description 
of object-oriented design and programming techniques see 
Object-Oriented Technology by David A. Taylor, Addison- 
Wcsley 1990. Object-Oriented Modeling and Design from 
General Electric Research and Development Center, 
Prentice-Hall 1991. and Object-oriented Software Construe- 
Hon by Bcrtrand Meyer. Prentice-Hall 1988. for exanqrfe. 
These three books are incorporated herein by reference. 

However, the full promise of object-oriented 
methodologies, especially the advantages afforded by their 
modularity, has yet to be achieved. In particular, it would be 
hig^y desirable to aUow programmers and other users 
access to objects in a transparent fashion so diat objects 
created in diifferent programming languages and objects 
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residing on different con^tlng platforms that are net- 
worked together are accessible to the user without extensive 
modification of the user* s progranuning code. 

The situation in which objects are located on different 

5 computers linked by a network is typically called client- 
server computing. In client-server computing, typically 
there is a set of computen that can conununicate with one 
another through a network connecting the computers. Some 
of these computers act as providers of services or function- 

10 ality to other computers. The providers of such service or 
functionality arc known as "servers", and the consumers of 
sudi service or functionality are called "clients". The client- 
server model also generalizes to the case where distinct 
programs miming on the same computer are communicating 

1^ with one another through some protected mechanism and are 
acting as providers and consumers functionality. 

Attends to {S'ovide such a distributed system have been 
made using object-oriented methodologies that are based 
upon a client-server model, in which server objects provide 

^ interfaces to client objects that make requests of the server 
objects, lypically in such a distributed system, these servers 
are objects consisting of data and associated methods. The 
client objects obtain access to the functionalities of the 
server objects by executing calls on them, which calls are 

^ mediated by the distributed system. When the server object 
receives the call it executes the appropriate method and 
transmits the result back to the client object. The client 
object and server object communicate throu^ an Object 
Request Broker (ORB) which is used to locate the various 

^ distributed objects and to establish communications between 
objects. 

The object metaphor in distributed systems is a useful 
technique as it s^>arates the object's interface from its 

3j implementation; thus allowing software designers to take 
advantage of the functionalities of various objects available 
to them without having to wcrry about the details of the 
object's implementation. The progranuner need only be 
aware of die object's interface. In addition, object oriented 

^ distributed systems allow for multiple implementations of a 
single interface, which interface may reside on different 
conqHjting platforms that have been connected through a 
network. Thus, a progranmier working on one machine of a 
network may make a call to an object about which the 
prograrmner has no detailed knowledge, with the confidence 
that the remote object will be called, a method will execute, 
and data will be returned properly. Such a system maximizes 
the inherent advantages of object-(mented methodologies by 
taking full advantage of their modularity and encapsulation. 

50 Another advantage of a distributed object system is that 
distributed objects are location-independent. That is, distrib- 
uted objects may exist anywhere in a network: in the client's 
address space; in multiple address spaces on tiie client's 
machine; and in multiple machines across the network. All 

55 objects are treated uniformly by clients, no matter what their 
location. Further, distributed object systems provide greater 
functionality than conventional systems since application 
developers can rely on existing inventories of objects to 
provide base level hmctionality. They also include improved 

50 portability since applications can cooperate through user- 
defined platform-independent interfaces and also facilitate 
reduced development cost Many odier benefits can be 
realized with a distributed object system as well. 
The software industry has responded to this need for a 

65 distributed object technology by forming the Object Man- 
agement Group (OMG). The goal of the OMG is die 
definition of the Object Management Architecture (OMA), 
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which has four major componeDts: the Object Request 
Broker (ORB). Object Services, Common Facilities, and 
Application Objects. The Object Request Broker provides 
basic object communicatioDS and management services, thus 
forming the basis of a distributed object systenL A standard 
for an Object Request Broker is contained in the Common 
Object Request Broker Architecture (CORBA) specifica- 
tion. 

One implementation of the OMG specification of a dis- 
tributed object system is called Distributed Objects Envi- 
ronment (DOE). In this inq)lementation. the functionality of 
the ORB is peiformcd by the Distributed Object Manage- 
ment Facility (DOMF). In o&er words, the DOMF provides 
the basic object services for the distributed object system. A 
description of the fundamental elements and functionality of 
DOE is contained in the Interface User*s Guide and Refer- 
ence: Project DOE External Developer's Release 2, May 
1994. by SunSc^ of Mountain View. Calif., and is herein 
incorporated by reference. (SunSoft is a trademark of Sun 
Microsystems, Inc.) 

In the distributed object system, all objects have types. 
These types are known to the client But in some cases, a 
client may only know of the general type of an object, yet 
wish to treat the object as a more specific type. This process 
of converting an object from a general to a specific type is 
called ^^nairowing**. For example, if a client knows that an 
object is in general a printer, it might prove useful to be able 
to perform more specific operaticms for a coIcm^ PostScript 
IHinter. Hiat is, the client wishes to be able to narrow down 
the exact type of the printer. A client would wish to query tfie 
printer object "are you really a color PostScript printer?" 
And in some cases, the client may wish to perform the 
reverse process and widen the type of an object Considering 
a client's need to narrow or to widen the type of an object 
it would be desirable to have a method and apparatus in a 
distributed object system to query an object about what type 
it is. 

SUMMARY OF THE INVENTION 

To achieve the fcregoiog and oAer objects and in accor- 
dance with the purpose of one aspect of the present 
invention, a method and qjparatus of checking the type of an 
object located on a remote counter in a distritnited object 
environment cornputing system is disclosed. In the type 
checking method, an inquiry is made as to whether the 
remotely located objea is a specified type. The ^>ecified 
type is typically referred to by an apparent interface iden- 
tifier. Initially, a type checking method to det^mine whether 
a remotely located object is of a specified type is invoked. 
In the invocation, a target interface identifier is included as 
an argument A dctomination is then made as to whether the 
target interface identifier is equal to or a base for an apparent 
interface identifier held by a proxy located on the first 
machine. Jf the target interface identifier is determined to be 
equal to or a base for the ^iparent interface identifier, an 
affirmative indication to that effect is returned to the client 
On the other hand, when the target interface is determined 
not to be equal to or a base for the apparent interface 
identifier the target interface identifier is then compared to a 
real interface identifier. In noany embodiments, a call to the 
server host will have to be naade in order to determine fte 
real interface identifier. In some embodiments, a local cache 
can also be provided to store the results of such inquiries. 
Tht target interface identifier is then conq>ared to the real 
interface identifier and a determination is made as to 
whether the target interface identifiex is equal to ch^ a base for 
the real interface identifier. The result is then returned to the 
client. 
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In embodiments that utilize a cache, the real interface 
checking step can first include the sub-step of checking 
whether the cache can make the determination as to whether 
the target interface identifier is equal to or a base for the real 
5 interface identifier. If so. the appropriate result is returned. 
If not a call is made to die second computer to determine 
whether the target interface identifier is equal to or a base for 
the real interface identifier. 
In one prefored arrangement when a call must be made 
10 to the server host to check the real interface, a connection is 
established between the client host and an ORB daemon on 
the second computer. The ORB daemon is then used to 
identify a real interface identifier and an interface def for the 
target object More specifically, the ORB daemon utilizes a 
13 target object identifier passed from the proxy to locate the 
real interface identifier and the interface def. The target 
object identifier is arranged to identify the target object to 
the second conqxiter. The interface def is then used to 
determine whether the target interface identifier is equal to 
20 or a base for the real interface identifier and the results arc 
returned to the proxy object located on the first computer. 

In another preferred arrangement, when a call must be 
made to the server host to check the real interface, a 
connection is established between the proxy and die server 
^ process on the second ccwnptiter. The determination as to 
whettier the target interface identifier is equal to or a base for 
the real interface identifier is then made by the server 
process and the result is returned to the client. 
In another aspect of the present invention, a method and 
^ apparatus for. checking the type of an object located on a 
remote computer and for returning an output proxy object is 
disclosed. A cast checking function checks the cast of the 
proxy object by coiiq>aring die target interface identifier to 
the ai^arent interface identifier and to the interfaces of all of 
the parent objects from which the proxy object inherits. If 
the cast cheddng fiinction is successful tlien the proxy 
object is returned, after being widened to the dass associated 
widi the target interface identifier. If the cast checking 
function is unsuccessful then a remote ^pe checking func- 
^ tion as described above is perfanned. If this type checking 
function is unsuccessful, then the null proxy is returned. If 
the fiinction is successful, then an output proxy is created by 
using a proxy factory table to indicate the ap|HDpriate proxy 
factory. The output proxy will be of the same kind as the 
proxy object, and of the same type as the target interface 
identifier. The output proxy will also be widened to the class 
associated with the target interface identifier. 

BRIEF DESCRIPTION OF THE DRAWINGS 

50 

The invention, together with further objects and advan- 
tages diereof . may best be understood by reference to the 
following description taken in conjunction with the accom- 
panying drawings in which: 

FIG. 1 is a rqiresentation of a distributed object system 
showing a client process running on the client computer, a 
server process running on die server computer, and objects 
within each process. 
FIG. 2 is a flow chart describing a method for determining 
go whether a target object is a specific type of an object in 
accordance with one enobodiment of the invention. 

FIG. 3 is a flow diatt describing a method of implement- 
ing the remote IS__A fiinction step of FIG. 2 in accordance 
with one embodiment of die invention. 
6S FIG. 4 is a flow chart desaibing a method of implement- 
ing the remote IS_A fiinction st^ of FIG. 2 in accordance 
with a second embodiment of .the invention. 
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FIG. 5 is a symbolic rep-esentation of tables that make up different programming languages. One sudi interface defi- 

a client cache. nition language is IDL. Second, distributed objects are 

FIG. 6 shows two embodiments of object references and location-independent, i.e., distributed objects can be located 

also how one embodiment of the object reference is used to anywhere in a netwwk. This contrasts sharply with tradi- 

access the real interface ID in the BOA database. 5 t'onal progranmiing objects which typically exist in a single 

FIG. 7 is a flow chart descriWng a method for determining ai^ress space: the address space of the cUent process, 

the type of a target object and also for returning a proxy Distributed objects can be dient objects or server objects, 

object in acc<»dancc with one embodiment of the invendon. depending upon whether they are sending requests to other 

FIG. 8 is a flow diart describing the steps used to cr^^ate ^ ''P^'"'^ requests from oAer objects. R^uests 

an output proxy of the same kind Is the input proxy and of '° J^'ftl «««^,.*7"8h. an Object Request Brote 

^ * • J (ORB) that IS aware of the locations and status of the objects, 

the same type as the target interface in accordance with one * . u- r * u- _* *u . j 

...■^V^-,. A client object refers to an object that sends a request to 

embodiment of Che invention. . • -Ir • r *• * -r *• m. 

^ . ^ , ^, another object for infonnation or to perform a function. The 

FIG. 9 IS a representation of a j^oxy factwy table. object that provides the information or performs the function 

FIG. 10 is a flow chart describing the steps used to ^5 referred to as the server object In other words, a cUcnt 

implement the CHECK_CAST function of FIG. 7. object "calls" the server object to "invoke" a method that is 

FIG. 11 is a pictorial illustration of various computers defined on the server object The server object is also 

linked together in a computer netwwk. referred to as the target object. Because objects are 

FIG. 12 illustrates diagramatically some the major multilingual, client objects need not have knowledge of the 

con^x>nents of one of the computers illustrated in FIG. 11. 20 in4>lemcntation iM^ogramming language of the server object. 

m rvcci^TTyrrrkXT rkxr Tiro vicc-versa. Client objccts and server objects in distrib- 

DETAILED W^OT^TON OF THE ^^^^ ^^j^j systems need only communicate in terms of the 

^^^^'^^^^^^ interface definition language. As noted above, the request by 

In the following description, for purposes of explanation, the client object and the server object's reply, are handled 

specific data and configurations are set forth in order to 25 by the ORB. It should be pointed out that the client object 

provide a thorough understanding of the present invention. and server object can exist within the same process, or in 

The preferred embodiment described herein is iir^lemented different processes on the same host computer, or on two 

as a portion of the Distributed Objects Environment (DOE) different host compters. 

system created by SunSoft, a business of Sun Microsystems, An object reference is an object that contains a pointer to 

Inc. However, it will be ^>parent to one. skilled in the art that 30 another object Additionally, an objea reference can include 

the present invention may be practiced without the specific a portion of memoiy (the "sub-object identifier**) which can 

details and may be implemented in various conoputer sys- be used for identifying a sub-object. Widi the excq>tion of 

terns and in various configurations, or makes or models of the sub-object idemifier, the creation and definition of object 

tightly-coupled processors or in various configurations of references will be familiar to those skilled in the art 

loosely-coupled mult^>rocessor systems. 35 Generally, object references exist only within a client pro- 

L DEFTNinON OF TERMS cess. They generally cannot be stored by one process and 

A distributed object system is in general an in^lementa- retrieved by a second process, nor can they be exported from 

tion of distributed object technology and refers to a com- a process. Object references are created when an object is 

puter system having distributed objects that communicate aeated in a server process and can be passed via IDL 

through an Object Request Broker (ORB). 40 (Rations. Each object reference can refer to only one 

The Object Request Broker (ORB) jvovides basic object object; however, several object references may refer to the 

communications and management sen^ices. thus forming tiie same object 

basis of a distributed object system A object request broker To marshal a padcet of information is to prepare this 

daenK>n is a process running on a host computer which is the infonnation for transfer over a network conununications 

incarnation of the ORB on the host con^)uter. Tbus. eadi 45 line. This often means organizing the data in a particular 

host within a distributed object system has its own ORB format in accordance with the network communications 

daemon. One of the purposes of the ORB daemon is to start protocol being used. 

server processes. Collectively, the ORB daemons fona a To unmarshal a packet of infonnation is to essentially 

portion of the overall ORB. reverse the marshaling procedure to thereby produce a 

A client process is a software process that is running on 50 packet of information which is meaningful in a non-network 

or active on the client computer. A server process is a environment. 

software process on the server computer. It is conceivable An object interface is a specification <^ the operations, 

that the client process and the server process would be attributes, and exceptions that an object provid^. In one 

present on the same machine, and at times, may even be the embodiment, object interfaces for distributed objects may be 

same{^ocess. 55 written using an IDL. As noted above, objects perform 

An interface definition language (IDL) is a language that transactions through their interfaces. The use of interfaces 

is used to define the interfaces of objects. therefore relieves an object from having to know other 

The term object or distributed object refers to an encap- programming languages used to define the methods and data 

sulatcd package of code and data that can be manipulated by of other objects in the transaction. 

operations through the interface of the object. Thus, those of 60 A parameter is a data element sent fi-om a client object 

skill in the art will note that distributed objects include the along with a requested method to provide tfie server object 

basic properties that define traditional programming objects. wi& the necessary infcumation to perform the requested 

However, distributed objects differ from traditional pro- service. A parameter is also refenod to as an argument 

gramming objects by die inclusion of two inqwrtant fea- EL SPECIFIC EMBODIMENTS 

tures. First, distributed objects are multilingual The inter- 65 In a distributed object operating environment requests 

faces of distributed objects are defined using an interface and replies are made througli an Object Request Broker 

definition language that can be mapped to a variety of (ORB) that is aware of the locations and status of the objects. 
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One architecture which is suitable for imi^emeotiog such an 
ORB is provided by die common object request broker 
architecture (CORBA) specification. The CORBA specifi- 
cation was developed by the object management group 
(OMG) to define the distributed computing environment 
world in terms of objects in a distributed client-server 
environment, where target objects are capable (rf providing 
services to clients requesting the service. In the following 
discussion, the terms "object" and "distributed object" will 
be used Interdiangeabiy. as the following invention is 
directed to both types. 

In a preferred embodiment of the present invention, 
distributed objects are located on one or more computers 
linked together by a network. The network may take any 
suitable form. By way of example a r^esentative network 
arrangement 2 is illustrated in FIG. 11. The network anange- 
ment 2 includes a first computer 3 which is coupled to a 
transmission line 4. The network 2 further includes a server, 
router or the like 5 in addition to other computers 6. 7. and 
8 such that data and instmctions can be passed among the 
networked computers. The design, construction and imple- 
mentation of conoputer networks will be familiar to those of 
skill in the art. 

A rq>resentative computer 10 suitable for use as comput* 
ers 3. 6. 7. and 8 of FIG. II is illustrated schematically in 
FIG. 12. Computer 10 Includes a central ]»x»cessing unit 
(CPU) 12 which is coupled bidlrectionally with random 
access memory (RAM) 14 and unidirectionally with read 
only memory (ROM) 16. Typically, RAM 14 is used as a 
*'saatch pad" memory and includes progranmiing instruc- 
tions and daU (including distributed objects and their asso- 
ciated data and instmctions) for processes currently operat- 
ing on CPU 12. ROM 16 typically includes basic operating 
instructions, data and objects used by the computer to 
perform its functions. In addition, a mass storage device 18, 
such as a hard disk. CD ROM. magn^o-optical (floptical) 
drive, tape drive or the like, is coupled tndirectionally with 
CPU 12. Mass storage device 18 generally includes addi- 
tional programming instructions, data and objects that typi- 
cally are not in active use by the CPU. although the address 
space may be accessed by tfie CPU. e.g.. for virtual memoiy 
or the Uke. Each of the above described computers further 
includes an input/output source 19 diat typically includes 
input media such as a keyboard, pointer devices (e.g.. a 
mouse Gt stylus) and/or network connections. Additional 
mass storage devices (not shown) may also be connected to 
CPU 12 through a n^ork connection. Jt will be appreciated 
by those skilled in the art that the above described hardware 
and software elements, as well as networidng devices are of 
standard design and construction, and will be well familiar 
to those skilled in the art 

Turning now to FIG. 1. FIG. 1 symbolically illustrates an 
example of a distributed object system 20. In an 
embodiment, the distributed object system is implemented 
by the Distributed Object Environment (DOE) of Sun 
Microsystems, Inc. The system includes a client con^uta 
22. a server conq}uter 24, and an Object Request Broker 
(ORB) 26 which is fH^esent on eadi computer and throughout 
the distributed object system 20. Also shown is a client 
process 28 which contains a client object 29, a proxy object 
30. its apparent interface 32, a local client cache 34 and stubs 
36. A server process 38 contains objects 40 and 41. the real 
interface 42 of object 40, and skeletons 44. A network 
conmiunication device 46 provides cotmnunication between 
the client computer 22 and the server coix^Miter 24. 

The distributed object system 20 shows only one client 
computer 22 with a client process 28, and only one server 
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con^uter 24 with a server process 38. However it should be 
appreciated that there could be any number of conoputers 
and processes in a distributed object system, and there may 
be many processes on a given computer. Also, a given 

5 conqiuter or process could be either a client or a server, 
depending upon whether the computer or process is request- 
ing information about an object or receiving such a request. 
If a process is requesting information about a target object, 
it is termed the client process, and if a process contains the 

10 target object, it is termed the server process. Also it is 
conceivable that both the client process 28 and the server 
process 38 could be running on the same host conkputer. 
Although the methods describe herein may be used to handle 
same host inquiries, in most cases, more efficient procedures 

15 would be used to handle same host inquiries. The client 
computer 22 and the server con^uter 24 may be any type of 
computing device c{q>able of supporting objects, including 
super-computers, minicoixq>uters, workstations, penonal 
computers, personal digital assistants and other electronic 

20 computing devices. In general, the client process 28 and the 
server process 38 are software processes running on a 
confer in a defined memory space. These processes may 
be written in different programming languages. A process 
could be an operating system, an {plication program, a 

25 database, a device driver, network communications or other 
software based program. 

Contained within the client process 28 memoiy space are 
the stubs 36. any number of client objects 29. any number of 
proxy objects 30. and a local client memory cache 34. The 

30 stubs 36 are source code components that allow the client 
process 28 and server process 3S to communicate. A stub 
receives a function or procedure call in the native language 
of the client process 28 and uses support libraries to call to 
the server process 38. An analogous piece of software in die 

35 server process 38 are the skeletons 44. A skeleton performs 
an inverse mapping to what a stub i^ovides. A skeleton takes 
information that was encoded for the call and reconstitutes 
data structures or object references in the native program- 
ming language for the server process side of the call Both 

40 the stubs 36 and the skeletons 44 are partially implemented 
in the ORB. There will be a unique skeleton and stub for 
eadi interface, and thus any number of stubs in the client 
process and skeletons in the server process, respectively. 
The Interface Definition Language (SDL) compiler prefer- 

45 ably generates the smbs and the skeletons. 

As will be described in noore detail below, the client cache 
34 is used in some embodiments to speed the determination 
of the type a[ an object The drawback of using such a cadie 
is that it adds some overhead to the system. In the described 

50 embodiments in which it is used, the client cache 34 is in the 
same memory space as the client process 28. If ttie specific 
type of an object has been determined eariier, this informa- 
tion will be stored in the client process memory space where 
it can be accessed much faster than making a call over the 

55 network 46. FIG. 5 illustrates the structure of the client 
cache 34. The client cadie 34 is essentially a main table 150 
with pointers to value tables 152. Each row in the main table 
150 has a real interface ID (real interface identifier) field 154 
and a pointer field 156. Eadi row entry in the main table 150 

60 will be associated with a unique value table 152. That is. for 
each real interface ID contained in the real interface ID field 
154, there will be a pointer 157 contained in the pointer field 
156 that points to unique value table 152. 
Each row entry of a value table 152 has an interface type 

65 field 158 with a otxrespondlng value field 160. Thus, for a 
particular interface type ccmtained in die interface type field 
158, there will be a corresponding value contained in die 
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value field 160. The rows in the main table and value tables described embodiment, this is accomplished by executing an 

are filled in two ways. Rows are aeated and values assigned IS_A command. The goal of the IS_A method is to 

at compile time if the compiler has this information from the determine whether the target object 40 supports a specific 

stubs and skeletons. Also, as the client process 28 makes interface. In some cases, the client may know certain general 

object calls and learns this information, it will create these 5 information about a target object but may not know whether 

rows and tables for future use. How the client cache 34 is the target object is of a specific type. For example, the client 

specificaUy used is described below. |xocess 28 may know that the target object is a printer, but 

Returning now to FIG. I. the client object 29 is an object it wishes to ask die target object, **Are you a color postscript 

present in the memory space of the client process 28. A call printer?" The IS_A method is a Boolean function that will 

to a target object 40 (for example) to deteimine its type may lo return "Yes" or **No". In other cases, the client may not 

odginate from the client object, from the client process know anything about the target object's type and sin:4)ly 

itself. Off firom another entity in the client process. The proxy needs to know whettier it is a specific type of object. For 

object 30, as its name inq>lies. serves as a proxy for the example, the client may wish to know whether the target 

actual target object that the client process is trying to calL object is a 'folder**, whidi is presumed to have certain 

Thus, the client process will create a proxy for each target 15 properties. 

object with which it is in communication. The proxy con- Initially, in step 62. the client process 28 invokes the 

tains the object reference for the target object, thus allowing IS_A method by calling the proxy object 30 with the target 

the proxy to find the location of the target object. FIG. 1 interface ID as the argument to the method. The target 

illustrates a situation in which the target object 40 that the interface ID is the infornkation that the client process is 

client process wishes to call is located on another counter 20 trying to determine about the target object That is, the client 

24. in another process 38. In this situation, the client process is asking whether the target object supports the interface 

28 will make a call to the proxy object 30 (thinkbg that it identified by the target interface ID. Using the above 

is calling the target object 40). As the proxy object is in the example, the target interface ID would be "color postscript 

same address space as the client process , the call to the proxy printer^ . 

can be performed with a C++(or other suitable) function call. 25 The proxy may know the general type of the target object 

The proxy object will perform the marshaling and send ttie or even its specific type. The proxy will always have some 

information to one ofthe skeletons over the n^ork 46. The type information about the target object but it may only 

skeleton will act like the client process while querying the know that the target is of the type "object", the root type, 

target object 40. The skeleton will receive the desired This type information that the proxy has is the apparent 

information, pass it back to die proxy object 30 which in turn so interface ID. The apparent interface ID is stcfed as a field in 

acts like the target object 40 in returning the result to the the proxy object or is in^)licitly known to the proxy. By way 

client process 28. of cxaniple, in a system implemented in C+-I-, the C++ type 

As shown in FIG. 1. the ORB 26 is j^sent on each information may be used to determine some general type 

computing device (in this case the client con^Hiter 22 and information abcut the target object. Each proxy object will 

the server computer 24) and also across the network 46. Hie 3S have a function (called a CHECK_JD function) to imple* 

ORB provides basic object communication and management ment the IS__A method, but each function will be different, 

services. depending upon the type of the proxy. The functicm may be 

As defined above, an object*s interface specifies the implemented in any suitable form. By way of example, it 

nature of the object Here, the real interface 42 of the target may be a C++ virtual function. In step 64, the target interface 

(^ject 40 contains the actual information about the object 40 ID is compared to the apparent interface ID contained in the 

and the apparent interface 32 of the pdroxy object 30 may proxy object If the target interface ID is a base for or is the 

contain general information about the target object An same as the apparent interface ID then the IS^A method 

interface ID (interface identifier) is part of an interface and returns "Yes" in stq> 66 and terminates. If not. the IS_A 

identifies the type of an object. For example, the interface ID method moves to stq> 68. 

may indicate that an object is of a type "printer". Thus, the 4S In stq> 68 a call is made to execute a remote IS^A 

real interface ID of the real interface 42 may indicate function. This step effectively makes a call over the netwo-k 

specific type information about the target object (e.g. "I am because needed information has not been found in the proxy 

a postscript printer"), and the apparent interface ID object contained in the address space of the client process, 

(apparent interface identifier) may indicate general type Two suitable methods of performing a remote IS_^ func- 

information (e.g. '1 am a printer"). 30 tion are described below, and shown in FIGS. 3 and 4 

A general type is said to be a "base" for a specific type if respectively. In effect the remote IS_A function asks the 

the specific type is a member of the class of objects that the server directly whether the target object is of the desired 

general type describes. For example, the more general type type. Thus, it determines whether the target Interface ID is 

'printer" is a base for the more specific type "color post- the same as or a base for the real interface ID. In response 

script printer" because a color postscript printer is a printer. 55 it receives a Boolean "Yes" or **No" answer. 

The type "color postscript printer" would not be a base for After a response is received Step 76 determines whether 

the type "color printer" because a color printer is not the remote IS_^ function returned a "Yes" or *t^o" result 

necessarily a color postscript printer. In object-oriented If the result is "Yes", step 78 returns a "Yes" and the IS_^ 

programming terms, it can be said that a general type is a method terminates. If the result is "No", step 80 returns a 

base for a specific type if the specific type is a sub-class of 60 "No" and the IS_A method terminates, 

the general type. Thus, since an interface ID indicates the Referring next to FIG. 3 a process 68a suitable for 

type of an object it is possible to compare and determine if performing a remote IS_^ function (step 68 of FIG. 2) In 

a target interface ID (target interface identifier) is a base far accordance with a first embodiment will be described. In (his 

either an apparent interface ID or a real interface ID. embodiment, die real interface ID is not part of the object 

Referring next to FIG. 2 a method 60 by which a client 65 reference. Initially, in stq> 92. the proxy object establishes a 

may determine the type of a target object in accordance with connection with the ORB daemon on the server's host 

one embodiment of the invention will be described. In the machine. The identity of the host is provided in a host name 
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field in the object refereDce. This Infonaation is used by the 
object request broker in order to identify die network port 
number of the server's ORB daemon* which in turn facili- 
tates the establishment of a connection. By way of exan^ie. 
a suitable mechanism for establishing and managing con- 
nections in a distributed object system is described in 
Brownell ct al/s co-pending U.S. patent application Ser. No. 
08/40S316, fUed Mar. 22. 1995, which is incorporated 
herein by reference in its entirety. 

After a suitable connection has been established, a call is 
made in step 94 from the client to the server's ORB daemon 
asking for the real interface ID and the Interface def for the 
target object. As shown in FIG. 6. the object ID from the 
target* s object reference 172 is used as the argument for this 
call. As this object reference is contained in the proxy object 
the client has direct access to fre object ID. The ORB 
daemon then uses the object ID to access a particular row in 
the server host's BOA database 176 which identifies the 
interface def and real interface ID for each of the distributed 
objects (including the target object) which are available on 
the server's host machine. The interface def is an object in 
an interface repository that contains information on all the 
interfaces of the distributed object system. The Interface 
repository Is described in the interface repository chapter of 
&c CORBA Specification, which is iocoiporated herein by 
reference. The interface def has its own ^^compare** operation 
for comparing the target interface ID to the real interface ID. 
This operation may be implemented in any suitable form, 
such as a C-Kfunction. 

Returning now to FIG. 3. once die ORB daemon has 
ideotiiied the interface def and real interface ID, they are 
returned in step 96 to the proxy object. In step 98, the 
conqwe operation of the inteif ace def is called by the proxy 
object with the target interface ID as die argument. In step 
100. the interface def object receives this request In step 
102. the coiiq>are (^>eration of the interface def object 
con^ares the target interface ID to the real interface ID and 
returns the result to the proxy. Next control returns to step 
76 of FIG. 2 which processes the result of the compare 
operation. 

Referring next to FIG. 4. a second implementation 68b for 
the remote IS^A function which is step 68 of FIG. 2 will be 
described. In this second embodiment the real interface ID 
is part of the object reference. Initially, in st^ 112 of this 
embodiment, the target interface ID is compared to the real 
interface ID using the local client cache. FIG. 5 shows a 
symbolic rq>reseatation of the dient cache 34. which has 
been explained above. Referring to FIG. 5. the comparison 
is done as follows. As die real interface ID is known from 
die object reference, this embodiment first locks in the main 
table 150 through the real interface ID fields 154 to find the 
appropriate real interface id. Then the corresponding pointer 
field 156 is used to access a pointer 157. This pointer 157 
will point to a value table 152 (for examfde) that may 
already have con4>arison information regarding the target 
interface ID. For example, if the real interface ID is "mono- 
chrome postscript printer", and the target interface ID is 
'•printer**, the value would be "Yes**. The value (or result) is 
'Tes** because a postscript printer is a printer. Likewise, if 
the target interface ID is "color printer^, the value would be 
''No" because a monochrome postscript printer is not a color 
printer. It may be that the client cache 34 does not have 
entries in a value table 152 yet for a particular target 
interface ID. In this case, the client cache cannot provide a 
'*Yes** or "No** value. 

Returning now to FIG. 4. step 114 processes the result 
obtained from using the client cache. If the target interface 
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ID is a base for or equal to the real interface ID. then step 
118 produces a ^Yes** result which is returned to the client 
in step 76 of FIG. 2 as explained above. If not. then step 116 
produces a '"No" result which is also returned in step 76 of 
5 FIG. 2. If the client cache does not have information (or does 
not have sufGcient information) regarding the relation 
between a particular real interface ID and a particular target 
interface ID, then the "don't know" brandi is followed to 
step 119. 

10 As in the previously described embodiment, a connection 
with the server host's ORB daemon must initially be made 
in step 119. Then, in step 120; the proxy object makes a 
remote IS^ call to the skeleton in die server process using 
the target interface ID as the aigument. This call across the 

15 network is necessary only when the local dient cache in the 
memory space of die client process does not contain the 
needed information. In step 122. the skeleton receives diis 
request from die proxy. In step 124. die skeleton performs a 
comparison operation implemented in C++ to compare the 

20 target interface ID to die real interface ID. As the skeleton 
is in the same memory space as the server process, the 
skeleton has direct access to the real interface ED. That is. as 
there is a unique skeleton per interface, the skeleton will 
inherendy have access to the real interface ID. 

25 Step 124 determines whether the target interface ID is 
equal to or a base for the real interface ID and returns the 
result to the proxy. Next step 126 updates the local client 
cache with the result, a "Yes** or a ^T^o" value, and then 
returns to step 76 of FIG. 2 as explained above. The client 

30 cache is updated as follows. Refenii^ again to FIG. 5. for 
a given real interface ID in the main table 150 of the client 
cache 34. a pointer 157 indicates the value table 152 for that 
real interface ID. The target interface ID diat is the subject 
of the query is then entered into the interface type field 158 

35 of the value taUe 152 along with the value that was returned 
by the skeleton ("Yes" or "No") into the value field 160. In 
this way. the result of this call to die skeleton can be saved 
locally in the client cache 34 for future use. The advantage 
is diat if the same IS_^ query is invoked again, the result 

40 can be obtained quicker in the local client cache instead of 
making a call to the skeleton over the network. 

In a third possible embodiment of the IS_>V function, 
steps 94 dirough 98 of FIG. 3 could be combined. The cache 
would be buOt into the ORB daemon, and die ORB daemon 

45 would call die interface def. 

FIG. 6 shows the object reference — ^BOA database rela- 
donshq) 170. In a first embodiment <^ the IS_A method die 
object reference 172 is variable length word that contains 
information related to the tatg^ object This object reference 

50 is contained in the ptoxy object The object reference 172 
has fields that contain information about the host name, port 
number, object ID. and sub-object ID. The host name is die 
name of the machine on which the target object resides, and 
the port number is the network port number for the server 

55 process *s ORB daemon. In a second embodiment of die 
IS_A method, die object reference 174 is similar to the 
object reference of the first embodiment, but the object 
reference 174 also has a field that contains the real interface 
ID. 

60 Also shown in FIG. 6 is the BOA database 176. The BOA 
database 176 is a table of information about each object in 
the distribiited object system Each machine in the distrib- 
uted object system wiU have its own BOA database that 
keq>s track of all the objects on that machine. Each row of 

65 the table corre^nds to an object, and a row is added and 
filled with infonnation each time diat an object is created. 
The ORB daemon builds and maintains this table. This table 
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176 contains information on each object such as the object 
ID. the interface def. the in^jiementation dcf, reference data 
and the real interface ID. The interface def and implemen- 
tation def are object references to objects of type *lnterf ace- 
Def and *TmpiementationDer. which stand for interface 
defimtion and in^lementation definition. Both are described 
in the OMG document *The Common Object Request 
Broker: Architecture and Specification". No. 93,12.43. 
December 1993, which is herein incorporated by reference. 
This table 176 can hold other Information besides the data 
shown. 

In a distributed object system, the ORB n^y have many 
object adapters. In a DOE embodiment of a distributed 
c^ject system, there is only one object ad^er which is the 
Basic Object Adapter (BOA). However, it is contemplated 
that there could be many object adapters for tiie ORB, in 
which case there would be a table such as the BOA database 
176 corresponding to each object adapter. 

Referring next to FIG. 7 a NARROW operation 180 in 
accordance with one embodiment of another aspect of the 
invention will be described. The goal of the NARROW 
method is to return a new proxy object to the client process. 
The new proxy will typically have an apparent type that is 
more specific than that of the input proxy. In effect, the 
NARROW operation will create a new proxy (referred to 
herein as an output proxy) in the same memory space in the 
client process as an old proxy (referred to herein as the input 
proxy). This new ouqHit proxy wiU also be of the same kind 
as the inpm proxy. The input proxy is the term given to fee 
original proxy object upon which the client process makes it 
first call. In diis embodiment of the NARROW mefeod, 
tiiere arc three implementations of proxy objects: locaL 
remote and null. A local proxy object is used for those target 
objects which are in the same memory space as the dient 
process. A remote proxy object is used for those target 
objects which are in the server process memory space tfiat is 
separate from the client process. A null proxy object repre- 
sents no object A null proxy can be in^emented by 
returning a null object* a null pointer or by dirowing an 
excq)tion. It is also contemplated feat feere could be ofeer 
kinds of proxy objects and indeed fee flexibility of handling 
ofeer types of proxies is considered a feature of fee 
described system. By way of exan:^e, ofeer kinds of proxies 
could include replicated proxies, which rqn-esent fee same 
object, but inq)lemented by other server processes on ofeer 
machines. 

Referring now to FIG. 7 in detail, fee NARROW invo- 
cation 180 begins in step 182 when the client process makes 
a call to fee class corresponding to fee target interface to 
implement its NARROW mefeod. The object reference is 
used as fee argument For example, if fee target interface ID 
is "colc»: printer**, feen fee NARROW mefeod for fee class 
*'color printer^ will be used. For each class of objects, feere 
will be a unique NARROW mefeod defined. Also* feere is 
a unique class defined for each interface. 

Next, in step 184 fee NARROW mefeod makes a call to 
fee input proxy object to perform fee CHEOL-CAST 
function wife fee target interface ID as fee argument Stqp 
186 pcrfojms fee CHECK_CAST function as will be 
described in more detail below wife reference to FIG. 10. 
CHECK_CAST will check fee inheritance tree of fee jwoxy 
object interface to determine if the target interface ID is 
equivalent to fee {^parent Interface ID of fee proxy object 
itself, or is equivalent to any of fee interface ID's of any oi 
fee parents. For example, if fee sqrparent interface ID of fee 
proxy object is "printer", and fee proxy object inherits (has 
parents) from fee classes "color printer" and "postscript 
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printer", feen fee CHECIC_CAST function will compare fee 
target interface ID to "printer**, "color printer" and **post- 
script printer". The function CHECK-CAST will return 
eifeer the proxy object or a nuU. The CHECK_CAST 

5 function will now be described in detail. 

Referring now to FIG. 10. fee CHECK_CAST function 
186 is shown. In step 260 fee target interface ID is compared 
to fee apparent inte^ace ID of fee proxy object. An equals 
comparison is used. For cxair^le, if fee target Interface ED 

10 is "color printer**, feen fee condition is satisfied only if fee 
apparent interface ID is exactly "color printer" as well. Note 
that this comparison operator is different from the compari- 
son q)erator used in step 64 of HG. 2. In step 64. fee 
comparison operator is "equal to or a base for**. Here in step 

15 260 of FIG. 10 fee comparison operator is "equal to". 

If fee target interface ID is equal to fee apparent interface 
ID, feen in step 272 a pointer to fee proxy object itself is 
returned and fee proxy object is also widened to fee class 
associated wife fee target interface ID. Widening is required 

20 because the proxy* s class is a combination of both fee 
interface class and fee inoplementation class. In C++ mul- 
tiple inheritance is used. The result of NARROW must be a 
proxy type of just fee interface class, so widening is used to 
hide fee implementation class. As fee CHECK^CAST func- 

25 tion is now finished, control returns to step 188 of fee 
NARROW mefeod. Step 188 oi FIG. 7 is described in detail 
below. In step 260 of FIG. 10 if fee target interface ID is not 
equal to fee apparent interface ID, feen fee function moves 
to step 264. 

30 Stop 264 determines if fee proxy object has any parents in 
fee interface inheritance tree. As used in this function, 
"parents" is defined to be bofe direct and indirect parents. 
For exan^>le, if an object does not inherit from any parent 
classes, feen step 264 would result in "no**. In this case, a 

35 null or zero is returned and control flows to step 188 of fee 
NARROW mefeod. However, if an object does inherit from 
one ot more parents, feen fee result is '*ycs** in step 264 and 
control moves to Step 268. 
Step 268 is a loop that aUows fee CHECK_CASr fiinc- 

40 tion to compare fee target interface ID to fee interface of 
each parent in fee inheritance tree. However, parent classes 
associated wife fee types *'raiiote proxy" or "local proxy" 
will not be used for comparison. Hiis lo(^ could be inq>le- 
mented in various ways. In one embodiment, this loop could 

45 be in^lemented using a recursive function that walks up fee 
inheritance tree, comparing fee interface ID of each parent 
to the target interface ID. In fact fee con^lete CHECK_ 
CAST function could be in^lemented as a recursive func- 
tion. Also, fee inheritance tree wiU not have cycles, but is 

50 iaiplemented as a directed, acyclic gr^h. Since fee IDL is 
defined so feat fee interface inheritance tree cannot have 
cycles, fee recursive function will terminate. In anofeer 
enfeodiment that is non-recursive, fee IDL compiler would 
create C++ code that would essentially **flatten out" this 

55 inheritance tree and provide explicit comparison code for 
each node in fee inheritance tree. 

Continuing wife step 268 of FIG. 10. step 268 first 
initializes a counter to zero, and feen checks to see if 
counter "i" is equal to fee nimaber of parents of fee proxy 

60 object. If counter "i" equals fee number of parents, this 
indicates feat fee interface ID of all parents have been 
compared to fee target interface ID and no match has been 
found. In this case, step 266 feen returns a null and control 
moves to step 188 of fee NARROW mefeod. However, if not 

65 all parents in fee inheritance tree have been checked, feen 
counter "i" will be less feen fee number of parents and 
control will move to step 270. In step 270. fee target 
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interface ID is con^ared to see if it is equivalent to the 
interface ID of the current parent node. If they are 
equivalent, then a match has been found and control moves 
to step 272. For example, if the proxy object has apparent 
interface "color postscript printer** which inherits from 
'^postscript printer^, and the target interface ID is '^postscript 
printer", then there will eventually be a match in an iteration 
of step 270, Step 272 will return the proxy object widened 
to the class associated with the target interface ID. After step 
272. control returns to step 188 of the NARROW method. 

In step 270, if the target interface ID is not equal to die 
parent interface ID, then control shifts back to step 268. 
counter 'T is inacased by one, and the next parent interface 
ID up the inheritance tree is checked against the target 
interface ID. This loop through steps 268 to 270 continues 
until either a target interface ID matches a parent interface 
ID (stq) 272). or until all parent interfaces have been 
compared and no match found (step 266). 

Step 188 of FIG. 7 is a decision block based on the results 
of the CHECK_CAST function. The function CHECK_ 
CAST is successful if a match occuned and the proxy object 
was returned. CHECK_CACT is unsuccessful if no match 
was found, resulting In a null being returned. In step 188. if 
CHECie_CAST was successful then the NARROW method 
is done and there is no need Co further narrow the proxy 
object On the other hand, if ttie CHECK_CAST function is 
unsuccessful, then the rxKtbod continues to step 190. Step 
190 then executes a remote IS_A function and receives a 
*'Ycs" or "No" result as described above. By way of 
examine, either of the remote IS_A functions described 
above with reference to FIGS. 3 and 4 work well to poform 
this stq>. The decision block 192 then reviews the result 
from the remote IS_A function. If the result is "No**, then 
step 198 returns a null proxy object for the target class and 
the NARROW method tenninates. A *?^o** result indicates 
that the target object does not support the target interface ID. 
For example. If the target object is a postscript printer, and 
the target interface ID is "modem** then the result will be 
'•No**. A "Yes** result would indicate that the target object 
does support the target interface ID. For example, if the 
target object is a color postscript printer, and the target 
interface ID is "color postscript printer" then the result wiU 
be "Yes**. 

If the result in step 192 is "Yes", then step 194 will create 
a new ou^t jH-oxy. This new output proxy will be of the 
same kind as the input proxy and of the same type as the 
target interface type. This step 194 is explained in more 
detail below with reference to FIG. 8. After the new ou^ 
proxy has been created, step 196 returns this output proxy 
widened to the class associated with the target interface ID. 
The output proxy is returned to die client process in the 
memory space of the client process. After step 196 the 
NARROW method is complete. 

Referring next to FIG. 8, the new proxy output creating 
step 194 of FIG. 7 will be described in more detail. Initially, 
step 212 determines the kind of ou^ut proxy needed based 
on the kind of the input proxy. The output proxy will be of 
the same kind as the input proxy. By way of example, in the 
example given above, there were three kinds of proxies: 
local, remote, or null. Thus, in that example, if the input 
proxy was a local proxy, the output proxy would be a local 
proxy. If the input proxy was a remote proxy, the output 
proxy would be a reiiK>te proxy. Again, one of the features 
of the invention is that it permits the use of other kinds of 
proxies as well. The only limitation is that if other kinds of 
proxies are used, the output proxies would be constrained to 
be the same kind as their input proxies. After the kind oi the 
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input proxy has been determined, step 214 uses a proxy 
factory table to determine the appropriate proxy factory for 
the determined proxy kind and the given target interface 
type. By way of exairq)lc. the structure of a representative 

5 factory table 240 is Ulustrated in FIG. 9. 

Referring now to FIG. 9. each row 242 in factory table 
240 represents a class of objects, while each column 244 
represents a different kind of proxy. Rows and columns 
intersect in cells 246. Based upon a particular kind of proxy 
(a column), and a given target interface type (a row), the 
table 240 will indicate the appropriate proxy factory to use 
to create the new output proxy. For exaii^>le, if the kind of 
input proxy is ''Remote*', and tfie given target interface type 
is **Printer**. then the aj^opriate proxy factory is '*#!**. This 
factory will produce proxy objects of interface type 

15 "Printer** and kind **RenK)te**. There will be a unique proxy 
factory for cadi cell 246. That is, the Oh- code that 
implements a given proxy factory will in general be 
different, but portions of the proxy factory in^lementing 
code may use conunon code. The IDL compiler registers the 

20 proxy factories in the proxy factory table. 

Returning now to FIG. 8. once the impropriate proxy 
factory is determined, step 216 creates an output ptoxy by 
calling the ^ropriate proxy factory with the input proxy as 
the argument The proxy factory returns the desired output 

25 proxy, which is of the same kind as the input proxy and of 
the same type as the target interface ID. The logic then flows 
to step 196 as described above with reference to FIG. 7, 
wherein the output proxy is widened to the class associated 
with the target interface ID. 

Although only a few embodiments of the present inven- 
tion have been described in detail, it should be understood 
that the present invention may be embodied in many other 
specific forms without departing from the spirit or scope of 
the invention. Particulariy, regarding the networic commu- 
nications device 46 of FIG. 1. it need not necessarily be an 
electronic, cabled network. That is, the transmission line 4 of 
FIG. 11 may be embodied in another form. For example, die 
computers may communicate via infrared waves, micro- 
waves or other electromagnetic media. Therefore, the 

^ present exarr^>les are to be considered as illustrative and not 
restrictive, and the invention is not to be limited to the details 
given herein, but may t>e modified within the scope of the 
appended claims. 
We claim: 

1. An apparatus for nanowing the type of a targ^ object 
in a distributed object environment computing system, the 
conq>uting system including a first computer and a second 
computer and wherein the target object is Intended to reside 
in a computer-controlled process executing on the second 
^ computCT. die i4>paiatus comprising: 

a) a client located on the first computer; 

b) a proxy object intended to reside in a computer- 
controlled process executing on the first computer 

c) a calling medianism for invoking a type checking 
55 method using a target interface identifier as an argu- 
ment to determine whether the target object is of a 
specified type, the target interface identifier indicative 
of a possible type of the target object; 

d) an apparent c(«npiarison mechanism for determining 
60 whether the target interface identifier is equal to or a 

base for an ^>parent interface identifier held by the 
proxy object, the qjparent interface identifier indicative 
of a possible type of ttit target object, wherein when the 
target interface identifier is determined to t>e equal to or 
65 a base for the apparent interface identifier, the apparent 
coiiy>arison mechanism is arranged to return an affir- 
mative narrowing indication to the client; 
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e) a communicatioD device for establishing a connection 
with an object request broker daemon on the second 
computer; 

f) a target object identifier located on the first computer 
that identifies the target object to the second computer ^ 

g) an identification mechanism for utilizing the object 
request broker daemon and the target object identifier 
to identify a real interface identifier and an interface 
definition object for the target object; and 

h) a real comparison mechanism located on the second 
computer utilizing die interface definition object fcH- 
comparing the target interface identifier to a real inter* 
face identifier and fcs determining whether the target 
interface identifier Is equal to or a base for the real 
interface identifier, the real interface identifier indica- 
live of the type of the target (*ject. wh^ein when die 
target interface identifier is determined to be equal to 

a base for the real interface identifier, an affirmative 
narrowing indication is returned to the client and 
wherein when the target interface identifier is deter- ^ 
mined not to be equal to <»- a base for the real interface 
identifier, a negative narrowing indication is returned to 
the diem. 

2. An apparatus as recited in claim 1 wherein the client is 
a client object intended to reside in a computer-controlled 
process executing on the first computer. 

3. An apparatus as recited in claim 1 wherein the first 
computer and the second computer are the same computer. 

4. An apparatus for narrowing the type of a target object 

in a distributed object envircHiment con^ting system, the ^ 
computing system including a first computer and a second 
computer and wherein the taiget object is intended to reside 
in a computer-controlled process executing on the second 
con^>uter, the apparatus con^sing: 

a) a client located on die first computer; 

b) a proxy object intended to reside in a computer- 
controlled process executing on the first oonqnitcr; 

c) a calling medianism for invoking a type checking 
method using a target interface identifier as an argu- ^ 
ment to determine whether the target object is of a 
specified type, the target interface identifier indicative 
of a possible type of the target object; 

d) an ^>parent comparison mechanism for determining 
whether the target interface identifier is equal to or a 4^ 
base for an apparent interface identifier held by the 
proxy object, the apparent interface identifier indicative 
of a possible type of the taiget object wherein when the 
target interface identifier is determined to be equal to or 

a base for the parent interface Identifier, the apparent ^ 
comparison medianism is arranged to return an a£6r- 
mative narrowing indication to the dient; 

e) a real comparison mechanism for comparing the target 
interface identifier to a real interface identifier and for 
deteimining whether the target interface identifier is 55 
equal to or a base for the real interface identifier, the 
real interface identifier indicative of the type of the 
target object; 

f) a cache memory located on die first computer; and 

g) a cache-checking device utilizing the real comparison 60 
mechanism for determining whether the taiget interface 
identifier is equal to or a base for tfie real interface 
identifier, wherein when said taiget interface identifier 

is determined to be equal to or a base for said real 
interface identifier, said cache-checking device is 65 
arranged to return an affirmative narrowing indication 
to said client. 
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5. An apparatus as recited in claim 4 wherdn the client is 
a computer-controlled client process executing on the first 
cofx^uter and the cache memory Is located in the client 
process. 

6. An apparatus as recited in claim 4 further comprising: 

a) a communication device for establishing a connection 
with an object request broker daemon on the second 
computer; 

b) a daemon comparison mechanism for utilizing the 
object request broker daemon to determine whether the 
target interface identifier is equal to or a base for the 
real Interface identifier; and 

c) a cache-updating device for updating the cache 
memory based on the object request broker daemon's 
determination. 

7. A method as recited in daim 4 wherein said first 
computer and said second computer are the same computer. 

8. An apparatus for narrowing an input proxy object 
intended to reside in a computer-controlled process execut- 
ing on a first computa in a distributed object environment 
computing system, the apparatus comprising: 

a) a client located on a first conq>uter; 

b) a target object intended to reside in a con^uter- 
controlled process executing on a second computer; 

c) a checking mechanism for perf<^ming a check cast 
function on the input proxy object using a target 
interface identifier, the taiget interface identifier indica- 
tive of a possible type of the taiget object, the checking 
mechanism conq>aring the target inteaface identifier to 
an apparent interface identifier of the input proxy object 
and to interface identifiers, of all parent objects of the 
input proxy object the a^arent interface identifier 
indicative of a possible type of the target object; 

d) a communication device for establishing a connection 
with an object request broker daemon on the second 
computer. 

e) a target object identifier located on the first con^ter 
that identifies the taiget object to the second computer; 

f) an identification mechanism for utilizing the object 
request broker daemon and the target object identifier 
to identify a real interface identifier and an interface 
definition object for the target object; 

g) a real comparison mechanism utilizing the interface 
definition object for comparing the target interface 
identifier to a real Interface identifier associated with 
the targ^ object and fCH* determining whether the target 
interface identifier is equal to or a base for the real 
interface identifier, the real interface identifier indica- 
tive of the type of the target object; and 

h) a seating device for creating an ou^ut proxy object of 
the same kind as &e input proxy object and of the same 
type as the target iiiterface identifier. 

9. An ^^>paratus as redted in claim 8 further comprising 
a widening mechanism for widening die output proxy object 
to a class associated with the taiget interface identifier. 

10. An apparatus as recited in claim 8 wherein the client 
is a computer-controlled client process executing on the first 
computer. 

11. An apparatus as recited in claim 8 wherein the dient 
is a dient object intended to reside in a computer-controlled 
process executing on the first computer. 

12. An apparatus as recited in daim 8 wherein the first 
con^uter arid the second computer are the same con:q>uter. 

13. An ^paratus as recited in daim 8 wherein the creating 
device for creating an ou^ut proxy object includes a proxy 
factory table. 
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14. An apparatus for narrowing an input proxy object 
intended to reside in a computer-controlled process execut- 
ing on a iirst con^uter in a distributed object environment 
computing system, the apparatus comprising: 

a) a client located on a first computer; ^ 

b) a target object intended to reside in a coftq)uter- 
coDtroUed process executing on the second computer; 

c) a checking mechanism for performing a check cast 
function on the input proxy object using a target 
interface identifier, die target interface identifier indica- 
tive of a possible type of the target object; 

d) a real comparison mechanism for determining whether 
the target interface identifier is equal to or a base for a 
real interface identifier associated with the target 
object, the real interface identifier indicative of the type 
of the ta^^ object; 

c) a creating device for arcating an output proxy object of 
the same kind as the input proxy object and of tbe same 
type as the target interface identifier; 20 

f) a cadie memory located on the first con]^uta'; and 

g) a cache-checking device utilizing the real comparison 
mechanism for detennining whether the target interface 
identifier is equal to or a base for the real interface 
identifier, wherein when the taiget interface identifier is 
determined to be equal to or a base for the real interface 
identifier, die creating device is arranged to create an 
ou^ut ptoxy object of the same kind as the input proxy 
object and of the same type as the target interface 
identifier. ^ 

15. An apparatus as recited in claim 14 wherein the client 
is a conq>uter-controlled client process executing on tbe first 
computer and the cache memory is located in the client 
process. 

16. An ^aratus as recited in claim 14 further con[q>ris- 
ing: 

a) a communication device for establishing a connection 
witti an object request broker daemon on the second 
computer; 

b) a daemon comparison mechanism for utilizing the 
object request tcokcr daemon to determine whether the 
target interface identifier is equal to or a base for the 
real interface identifier; 

c) a cache-updating device for updating the cache 43 
memory based on the object request broker daemon's 
determination. 

17. A method as recited in claim 14 wherein said first 
computer and said second conoputer are the same con^ter. 

18. A computer-in:^)leniented method of narrowing the ^ 
type of a target object in a distributed object environment 
con^>uting system that includes a client located on a first 
computer, said target object residing in a computer- 
controlled i»x>cess executing on a second con^uter and a 
proxy object located on said first compter representing said 
taiget object said method comprising the following under 
computer control; 

a) said client invoking a type checking method using a 
target interface identifier as an argument to determine 
whedier said target object is of a specified type, said ^ 
target interface identifier indicative of a possible type 

of said target object; 

b) detennining whether said target interface identifier is 
equal to or a base for an apparent interface identifier 
held by said proxy object located on the first computer. 65 
said apparent interface identifier indicative of a pos- 
sible type of the target object; 



c) wherein when said target interface Identifier is deter- 
mined to be equal to or a base for said apparent 
interface identifier, an affirmative narrowing indication 
is returned to said client; and 

d) wherein when said target interface identifier is deter- 
mined not to be equal to or a base for said ^>parent 
interface identifier, said method further coiiq)rises. 
establishing a connection with an object request broker 

daemon on said second con^uter, 

utilizing said object request broker daemon to identify 
a real interface identifier and an interface definition 
object for said target object, said real interface iden- 
tifier indicative of said type of said target object 
wherein said object request broker daemon utilizes a 
target object Identifier passed from said first com- 
puter to locate said real interface identifier and said 
interface definition object wherein said target object 
identifier is arranged to identify said target object to 
said second computer. 

utilizing said interface definidon object to compare said 
taiget interface identifier to said real interface iden- 
tifier and to determine whether said target interface 
identifier is equal to or a base for said real interface 
identifier, and 

returning the result of the interface definition object 
determination to said proxy object located on said 
first computer, wherein when said target interface 
identifier is determined to be equal to or a base foe 
said real interface identifier, an affirmative narrowing 
indication is returned to said client and wherein 
when said target interface identifier is determined not 
to be equal to or a t^ase for said real interface 
identifier, a negative narrowing indication is returned 
to said client 

19. A method as rcdted in claim 18 wherein the client is 
a dient object intended to reside in a con^uter-controlled 
process executing on the first computer. 

20. A mediod as recited in claim 18 wherein the first 
conq>uter and the second oon^uter are the same computer. 

21. A computer-implemented method of narrowing die 
type of a target object in a distributed object environment 
computing system that includes a client located on a first 
computer, said target object residing in a computer- 
controlled process executing on a second computer and a 
proxy object located on said first con^uter representing said 
target object said method comprising die following under 
computer control: 

a) said client invoking a type checking method using a 
target interface id^tifier as an argument to determine 
whether said target object is of a specified type, said 
target interface identifier indicative of a possible type 
of said taiget object; 

b) determining whether said taiget interface identifier is 
equal to or a base for an apparent interface identifier 
held by said proxy object located on die first coir^uter. 
said apparent interface identifier indicadve of a pos- 
sible type of the target object; 

c) wherein when said target interface identifier is deter- 
mined to be equal to or a base for said apparent 
interface identifier. an afiEirmalive narrowing indication 
is returned to said client; and 

d) wherein when said target interface identifier is deter- 
mined not to be equal to or a base for said apparent 
interface identifier, said method further comprises, 
checking a cache memory on said first computer to 

compare said target interface identifier to a real 
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interface identiiier, said real interface identlAer 
indicative of said type of said target object, 

determiniiig whether said target interface identifier is 
equal to or a base for said real inteiface identifier, 
wherein when said target interface identifier is deter- s 
mined to be equal to or a base fcf said real inteiface 
identifier, an affirmative narrowing indication is 
returned to said client, and 

wherein when such determination can not be made by 
checldng said cache memory, making a call to said lO 
second computer to determine whether said target 
interface identifier is equal to or a base for said real 
interface identifier. 

22. A method as recited in claim 21 wherein the client is 

a computer-controlled client process executing on the first 15 
computer and the cache memory is located in tiie client 
process. 

23. A method as recited in claim 21 wherein when the 
target interface Identifier is determined not to be equal to or 

a base for the q>parent interface identifier the method further 20 
comprises the following steps under computer control: 

a) establishing a connection with an object request broker 
daemon on the second computer; 

b) utilizing the object request broker daemon to determine 
whether the target interface Identifier is equal to or a 
base for the real interface identifier; 

c) returning the result of the object request broker dae- 
mon's determination to the proxy object located on the 
first computer; and 

d) updating the cache memory based on the results 
returned to the proxy object 

24. A method as recited in claim 21 wherein said first 
computer and said second conqxiter are the same computer. 

25. In a distributed object environment confuting system 
that includes a client located on a first computer, an infNit 
proxy object residing in a conq)utcr-contr<dled jwoccss 
executing on the first computer, and a target object residing 
in a computer-controlled process executing on a second 
computer, a computer-implemented method of narrowing ^ 
the input proxy object comprising the following under 
computer control: 

a) performing a check cast function on the iiq)ut fH-oxy 
object using a target interface identifier, the target 
interface identifier indicative of a possible type of the 4^ 
target object, the check cast function including the 
sub-stq)s of con[^>aring the target interface identifier to 
an apparent interface identifier of the input proxy 
object, the parent interface identifier indicative of a 
possible type of the target object, and the sub-step of 50 
comparing the target interface identifier to interface 
identifiers of all parent objects of the input proxy 
object; 

b) determining whether the dieck cast function is suc- 
cessful; and 35 

c) wherein if the check cast function is not successfiil. said 
method further conq)rises. 

establishing a connection with an object request broker 
daemon on the second computer. 

utilidng the object request broker daemon to identify a 60 
real interface identifier and an interface definition 
object for the target object the real interface identi- 
fier indicative of the type of the target object 
wherein the object request broker daemon utilizes a 
target object identifier passed from the first conqjuter 65 
to locate the real interface identifier and the inteiface 
definition object, and wherein the target object iden- 
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tifier is arranged to identify the target object to the 
second computer, 

utilizing the interface definition object to compare the 
target interface identifier to a real interface identifier 
and to determine whether die target interface iden- 
tifier is equal to or a base for the real interface 
identifier, and 

returning the result of the interface definition object 
determination to the proxy object located on the first 
conq)uter, wherein when the target interface identi- 
fier is equal to or a base for the real interface 
identifier, an output proxy object of the same kind as 
the input proxy object and of the same type as die 
target interface identifier is created. 

26. A method as recited in claim 25 further comprising the 
step under computer control of widening the output proxy 
object to a class associated with the target interface identi- 
fier. 

27. A method as recited in claim 25 wherein the cUent is 
a computer-controlled client process executing on the first 
computer. 

28. A method as recited in claim 25 wherein the client is 
a client object intended to reside in a con^iuter-controlled 
process executing on the first con^uter. 

29. A method as recited in claim 25 wherein the first 
computer and the second computer are the same computer. 

30. A method as recited In claim 25 wherein the step of 
creating an ou^ut proxy object is performed by using a 
proxy factory table in order to find a proxy factory based on 
the kind of the input proxy object and the type of the target 
inteiface identifier. 

31. In a distributed object environment computing system 
that includes a client located on a first compute, an input 
proxy object residing in a computer-controlled process 
executing on the first computer, and a target object residing 
in a computer-controlled process executing on a second 
computer, a computer-implemented method of narrowing 
the input proxy object coniprising the following under 
computer control: 

a) performing a check cast function on the input proxy 
object using a target interface identifier, the target 
interface identifier indicative of a possible type of the 
target object, the check cast function including the 
sub-steps of comparing the target inteiface identifier to 
an apparent interface identifier of the input proxy 
object, the apparent interface identifier indicative of a 
possible type of the target object and die sub-step of 
comparing the target interface identifier to interface 
identifiers of all parent objects of the input proxy 
object; 

b) determining whether the check cast function is suc- 
cessful; and 

c) wherein if the check cast function is not successful, said 
method further comprises. 

checking a cache memory on said first computer to 
conqp^e said target interface identifier to a real 
interface identifier, said real interface Identifier 
indicative of said type of said target object. 

determining whether said target interface identifier is 
equal to or a base for said real interface identifier, 
wherein when said target inteiface identifier is deter- 
mined to be equal to or a base for said real interface 
identifier, an output proxy object of the same kind as 
the input proxy object and of the same type as the 
target inteiface identifier is created, and 

wherein when such determination can not be made by 
checking said cache memory, making a call to said 
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second computer to determine whether said target 
interface identifier is equal to or a base for said real 
interface identifier. 

32. A method as recited in claim 31 wherein said first 
computer and said second computer are the same computer, s 

33. A method as recited in claim 31 wherein the client is 
a computer-controlled client process executing on the first 
computer and the cache memory is located in the client 
process. 

34. A method as recited in claim 31 wherein when the lo 
check cast function is not successful the method further 
comprises the following steps under computer control: 
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a) establishing a connection with an object request broker 
daemon on the second con^HJter; 

b) utilizing the object request broker daemon to determine 
whether the target interface identifier is equal to or a 
base f<^ the real interface identifier; 

c) returning the result of the object request broker dae- 
mon's detemunation to the proxy object located on the 
first con^uter; and 

d) updating the cache memory based on the results 
returned to the proxy object 

***** 
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